Skip to content

fix(115_open): refresh OSS STS token during multipart upload#2575

Open
CloudCauldron wants to merge 1 commit into
OpenListTeam:mainfrom
CloudCauldron:fix/115_open-oss-token-refresh
Open

fix(115_open): refresh OSS STS token during multipart upload#2575
CloudCauldron wants to merge 1 commit into
OpenListTeam:mainfrom
CloudCauldron:fix/115_open-oss-token-refresh

Conversation

@CloudCauldron
Copy link
Copy Markdown

Summary / 摘要

The 115 Open driver's multpartUpload obtained the Aliyun OSS STS token once and created the OSS client a single time, never refreshing it during the upload. The STS token expires in ~1 hour, so any single-file upload whose upload phase runs past that window (large files and/or a throttled source) failed with oss: SecurityTokenExpired and then InvalidAccessKeyId, aborting the transfer.

This refreshes the token after 45 minutes (safe margin under the ~1h lifetime): it calls UploadGetToken again and rebuilds the OSS client/bucket with the new credentials, reusing the same multipart upload session (imur) to continue uploading the remaining parts. The multipart session is identified by bucket + object + uploadId and is not bound to the credentials, so switching credentials mid-upload is valid.

  • User-visible: large/slow uploads to 115 (e.g. relaying multi-GB files from a rate-limited source) that previously failed mid-way now complete.
  • Implementation: a per-part elapsed-time check + a token-refresh closure. No public API / config / storage changes.

Note: the cookie-based driver drivers/115/util.go UploadByMultipart has an analogous bug — it refreshes ossToken on a 50-minute ticker but never rebuilds ossClient/bucket, so requests are still signed with the stale AccessKeyIdInvalidAccessKeyId. Left unchanged here to keep this PR focused and validated; happy to follow up in a separate PR.

  • This PR has breaking changes.
  • This PR changes public API, config, storage format, or migration behavior.
  • This PR requires corresponding changes in related repositories.

Related repository PRs / 关联仓库 PR:

  • OpenList-Frontend:
  • OpenList-Docs:

Related Issues / 关联 Issue

N/A — direct fix, no separate tracking issue.

Testing / 测试

  • go test ./... (未运行完整测试套件)
  • go build ./drivers/115_open/ and go vet ./drivers/115_open/ pass
  • Manual test: built a local image containing this change and ran a real 百度→115 relay of several ≥4GB files whose upload phase exceeded 50 minutes (source throttled to ~700 KiB/s). Before this change the uploads failed around the 50-minute mark with SecurityTokenExpiredInvalidAccessKeyId; after it, the token is refreshed at 45 minutes and the transfers complete successfully.

Checklist / 检查清单

  • I have read CONTRIBUTING.
  • I confirm this contribution follows the repository license, contribution policy, and code of conduct.
  • I have formatted the changed code with gofmt.
  • I have requested review from relevant maintainers or code owners where applicable.

AI Disclosure / AI 使用声明

  • This PR includes AI-assisted content.

Tools used / 使用工具:

  • Claude (Claude Opus 4.8)

Usage scope / 使用范围:

  • Code generation / 代码生成

  • Review assistance / 审查辅助

  • I have reviewed and validated all AI-assisted content included in this PR.

  • I have ensured that all AI-assisted commits include Co-Authored-By attribution.

  • I can reproduce all AI-assisted content included in this PR without any AI tools.

The OSS STS token returned by UploadGetToken expires in about 1 hour.
multpartUpload created the OSS client once and never refreshed it, so a
slow or large upload running past the token lifetime failed with
SecurityTokenExpired and then InvalidAccessKeyId, aborting the transfer.

Refresh the token after 45 minutes and rebuild the OSS client with the
new credentials, reusing the same multipart upload session (imur) to
continue uploading the remaining parts.

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant